京东APP OpenHarmony化的跨端开发探索
导读
本文主要介绍了京东App在适配OpenHarmony的预研情况，表现了业务和技术复杂度，同时介绍了JDMCube动态化框架在适配OpenHarmony的进展和阶段性成功以及后续规划。通过本文，读者可以全面了解到京东App的现状，包括业务和技术栈分布，以及了解OpenHarmony UI框架，同时可以打开读者的思维：现有App适配OpenHarmony并不是非得从0开始，可以利用现有跨端框架进行适配到OpenHarmony，进而快速适配App业务。背景
导读
本文主要介绍了京东App在适配OpenHarmony的预研情况，表现了业务和技术复杂度，同时介绍了JDMCube动态化框架在适配OpenHarmony的进展和阶段性成功以及后续规划。通过本文，读者可以全面了解到京东App的现状，包括业务和技术栈分布，以及了解OpenHarmony UI框架，同时可以打开读者的思维：现有App适配OpenHarmony并不是非得从0开始，可以利用现有跨端框架进行适配到OpenHarmony，进而快速适配App业务。背景
2022年7月27日，在《开放原子全球开源峰会》-OpenHarmony分论坛上，京东作为分享嘉宾，为大家带来了精彩的分享。京东积极拥抱OpenHarmony，并参与 OpenHarmony应用生态建设，分享中介绍了京东App适配OpenHarmony的探索，重点呈现了京东跨平台方案Aotu Taro和JD MCube在OpenHarmony上的实践。
其中Aotu Taro框架是业界领先的跨端跨框架解决方案，并在OpenHarmony开源项目组主导成立了CrossPlatformUI-SIG，通过Aotu Taro可以很便捷地开发、调试、发布鸿蒙及OpenHarmony应用，帮助开发人员快速构建鸿蒙及OpenHarmony应用。
JD MCube框架是京东自研的原生动态化框架，覆盖了京东app黄金流程业务，并赋能集团其他app，目前正在联合京东集团内部力量进行共建，暂未对外开源。
由于论坛上分享时间有限，很多细节无法展现，Aotu Taro目前是开源项目，欢迎大家到社区参与共建。应众多听众要求，这篇文章会细致地向大家介绍暂未开源的JD MCube框架在OpenHarmony的适配进展。
01 京东App适配现状分析
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开-Xms | -Xmx → t. m. framework. heap. size + t. m. task. heap. size
本文从业务角度和技术栈角度对京东App适配OpenHarmony系统进行分析。
1.1 业务多样性
目前京东App年度活跃用户5.8亿+，且90%以上都是通过客户端下单。京东App作为京东的主应用，承接了京东集团内各个BG\BU的业务需求，业务形态众多，需求迭代频繁，每个迭代版本承接业务方需求3000+，对应的研发团队规模上千人，分布在北京、上海、深圳、成都、南京等职场。在功能上，涵盖用户可见的复杂业务和用户不可见的底层能力以及支撑App的周边生态。
综合来看，京东App适配OpenHarmony涉及的团队和业务都非常多，适配难度也非常大。
1.2 技术栈多样性
京东App内用到的技术栈也很多，主要包括原生、H5&小程序、跨端，占比分别是55%、40%、5%（其中RN、Flutter占比较少，所以不展开介绍）。
在占比较多的原生、小程序、H5这部分，从代码量看，原生代码行数已经达到了千万级，H5与小程序在App内代码行数百万级，所以通过重写代码来适配OpenHarmony 几乎不可能短期完成。
目前在原生开发方式上，本文作者自研的JD MCube原生动态化框架在业务中覆盖占比近50%，而且后续也会持续提高JD MCube的占比；H5&小程序目前主要使用Aotu Taro框架开发。分析看来，通过将JD MCube&Aotu Taro适配到 OpenHarmony可以极大降低整个App的适配工作量。
02 JD MCube动态化框架简介
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开-Xms | -Xmx → t. m. framework. heap. size + t. m. task. heap. size
简单来说，JD MCube 使用统一的一套 DSL 来描述UI和事件，在各个平台上进行解析并映射成各平台的UI控件，最终渲染展示。具体可以参考之前发布的文章《京东App MCube动态化实践》。
03 JD MCube适配OH探索
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
期望通过JD MCube适配OpenHarmony，为京东集团内应用快速迁移 OpenHarmony平台提供解决方案。
3.1 技术方案对比
2. 声明式UI: 使用此方案，需要 OpenHarmony 提供相关的 Ets 命令式API，用于动态的创建和更新View，当数据改变需要更新View属性时，仍可以基于现有的状态管理机制做到View的自动更新，开发者不需要额外处理。
3. C++ API: 使用此方案，由于目前这一层面的API还没有对开发者暴露，需要 OpenHarmony 提供相应的开发环境，在View更新上，需要由开发者来实现状态管理。并且由于该方案使用了较为底层的API, OpenHarmony 的技术专家担心会对App及系统造成不稳定，不太建议该方案。
3.2 落地情况及阶段性成果
2、解析ViewNode -> View
每个ViewNode的名字对应一个视图解析器，用于创建对应View和解析相关属性。
ViewNode Tree 的解析入口，会递归解析ViewNode Tree，并会根据缓存来判断是要创建一个View还是更新已有View的属性。
创建View,其实是先构建了一个Row组件，内部调用解析方法，将构建出来的View添加到该Row组件上，同时也被添加到了最外层的Column上。
3、创建\更新View，属性赋值
以 FlexboxLayout 和 TextView 解析器为例，通过命令式API，创建出对应Flex和Text组件并对其设置相应的属性。这里需要注意的是，创建和更新的场景相应的代码是一致的，其区别只是有没有被添加到外层容器上。
效果
将xml模板文件+JSON数据通过上述流程之后，最终运行到了开发版上之后，渲染出了一个列表条目。
目前作者在 OpenHarmony 平台上，已通过Demo验证了 JDMCube 框架适配 OpenHarmony 平台的可行性。后续仍有很多工作要做，在和 Android\iOS 平台功能对齐上，作者的自研表达式解析引擎、二进制编解码、事件处理、模板管理、生命周期监听等等仍需要改造适配至 OpenHarmony 平台。在性能优化方面，模板文件的解析效率、使用命令式API创建和更新视图的效率也是发力的重点。
04 后续规划
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
大型APP适配OpenHarmony是北向应用生态面临的重要课题。在技术上，京东将持续推进自研原生动态化框架JDMCube和跨端跨框架解决方案Aotu Taro适配 OpenHarmony的进展，未来目标是作为应用低成本适配OpenHarmony 平台的技术方案，以助力行业发展与OpenHarmony应用生态繁荣。
如何让Java编译器帮你写代码分拣平台API安全治理实战Flutter状态管理新的实践
求分享
求点赞
求在看